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Abstract. We motivate and introduce a query language PrQL designed 
for inspecting machine representations of proofs. PrQL natively supports 
hiproofs which express proof structure using hierarchical nested labelled 
trees. The core language presented in this paper is locally structured 
(first-order), with queries built using recursion and patterns over proof 
structure and rule names. We define the syntax and semantics of locally 
structured queries, demonstrate their power, and sketch some implemen- 
tation experiments. 


1 Introduction 

Automated proof tools and interactive theorem provers are increasingly called 
upon to produce evidence of their claims, in the form of representations of proofs 
that may be independently checked or, perhaps, imported into other systems. 
Proofs must connect together atomic rules of inference and axioms in a sound 
way according to an underlying logic. Checking that this has been done cor- 
rectly is straightforward, although producing a proof in the first place may be 
extraordinarily difficult. 

Real proofs can be very large, perhaps consisting of tens or hundreds of 
thousands of atomic rules of inference. There are many things that are interest- 
ing to know about such objects, beyond the basic fact that they are correctly 
constructed. For example, some natural questions when inspecting a proof are: 

— What is the high-level structure of this proof, (how) can we break it down 
into pieces to understand it? 

— Given a proof of a property which exploits a set of domain-specific axioms, 
which axioms actually occurred in the proof? (Or, in a purely logical setting, 
does a proof rely on axioms of classical logic?) 

— Given a problem statement which contains some existential propositions as 
sub-formulae, which, if any, witnesses were found to make them true? 

— Does a large proof contain duplicated parts that could be abstracted (or 
generalised) into a separate lemma, using a cut-like rule to reduce the size 
of the proof? 
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When the user is trying to understand the proof construction process, there 
are natural questions which relate the constructed proof back to the procedures 
that produced it. If tactics are our notion of proof producing procedure, some 
questions relating the proof to the tactics that produced it are: 

— Given a set of tactics and a proof, which tactics were invoked in producing 
the proof and what subgoals did they solve? 

— Were any tactics used repeatedly in this proof, perhaps with similar or iden- 
tical inputs? 

— Did some tactics get invoked but do no useful work? 

— Given a failed proof (represented as a proof with unproved portions), which 
tactics were tried on the unproved portions? 

These sort of questions are not idle curiosities: they are useful for practical 
proof engineering , when managing and maintaining sets of properties, proofs and 
programs which create and check them. One of us (Denney) routinely resorts to 
low-level scripted tools to perform these kind of examinations when building 
large safety cases supported by formal proofs. 

We consider querying proofs here in a rigorous manner with the hope of 
enabling more general tools with clear foundations. In this paper, we introduce 
the basis of a query language PrQL designed specifically for querying proofs. 

Hierarchical structured proofs. The foundation we start from is Hiproofs HE], 
which provide a simple abstract notion of proof tree by composing atomic rules 
of inference from an unspecified underlying logic. Going beyond ordinary trees, 
they have a notion of hierarchy , by allowing labelling and nesting subtrees. This 
simple addition provides a precise and useful notion of structure in the proof 
which can be used, for example, for noting where a lemma was applied, or where 
a particular tactic or external proof tool produced a subtree. 

Contributions and paper outline. This paper contributes towards generic founda- 
tional aspects of theorem proving systems. Specifically, we design a proof query 
language from first principles, directly connected with a precise abstract notion 
of proof. With the help of some implementation experiements, we establish that 
it is useful. Although query languages for tree and graph structured data have 
been studied over the last decade or so, they have very rarely been applied to 
formal proofs. 

The rest of this paper is structured as follows. Section [2] introduces the un- 
derlying setting of hiproofs used in the rest of the paper. Section [3] describes 
the design decisions we took for our query language, and introduces it with a 
sequence of informal examples and their intended meanings. Section [4] then de- 
scribes the meaning of queries formally, and shows that example queries indeed 
have the denotations expected. In Section [5] we describe some experimental im- 
plementations of the query language. These are early ideas, presented to demon- 
strate some possible practical end points of our work rather than a complete 
implementation study. We give pointers and discussion of some related work in 
the concluding Section [6] 
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2 Hiproofs 


Hiproofs add structure to an underlying derivation system , a simple form of 
logical framework. We give a brief recap here, for fuller details please see | 2 | 1 | . 

A hiproof is built from (inverted) atomic inference rules a in the underlying 
derivation system, to which we give a functional reading: a hiproof maps a finite 
list of input goals [71 , . . . , 7„] to a list of output subgoals [yj , . . . , . Such a 

hiproof has the arity n — » m. A nested hiproof, appearing immediately inside a 
labelled box, has a single input goal which is the root of the tree at that level. 

Informally and graphically, we draw hiproofs as inverted trees with a nested 
structure. Denotationally, a hiproof can be understood as a pair of an ordered 
tree and a forest with the same set of nodes, subject to some well-formedness 
conditions. Syntactically, a hiproof can be written as a term s in this grammar: 


s 


a 

id 


[l\s 


si ; S2 


si 8> s 2 

0 


atomic 

identity 

labelling 

sequencing 

tensor (juxtaposition) 
empty 


(1) 


Fig. |T] shows an example hiproof term and its graphical representation in the 
middle. Boxes indicate nestings and have labels in their top corners; unlabelled 
boxes contain atomic rules. Tensor <g> places things side-by-side and sequencing ; 
builds “wiring” to connect things together, using identity to create wires where 
a goal is not manipulated. In the example, id exports the second subgoal from 
the atomic rule a outside the box labelled I. The empty proof () is useful when 
building proofs programmatically. 


Valid hiproofs. A hiproof is called valid if it corresponds to a real proof tree in 
the underlying derivation system. The hiproof term in Fig. [l] validates the proof 
tree shown on the right-hand side, where an input goal 71 is proved using the 
atomic inference rules a, b and c. Validity extends naturally to arbitrary hiproof 
terms that have more than one input goal; such a term corresponds to a finite 
sequence of proof trees. We write s h g\ — > <72 if s is valid in this more 


([Z] a ; b ® id) ; [m] c 


1 

b 

c 

r 





m 

c 




a 


Fig. 1 . A hiproof, its graphical representation and a proof it validates. 
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-a is an atomic inference 


s I- 7 


a h 7 — > [7ij--->7n] id h 7 — > 7 [l] s h 7 — >-5 (> h 


— > ff 52 h g — » g 2 

Si ; S2 f 91 > ff2 


Si h fll » ffl S2 h ff2 » ff2 

si 0 s 2 h gi A p 2 — > A P2 


Fig. 2. Validation of Hiproofs. 


general sense, taking a list of input (proven) goals g\ to produce a list of output 
(unsolved) goals g 2 ■ This relation is defined by the rules in Fig.[2j where A stands 
for list append. 

Validity checking can be seen as a way of adding goals to a hiproof; corre- 
spondingly, a valid hiproof can be seen as a nested labelling applied to a flat 
proof. In this paper we restrict our attention to valid hiproofs and we assume 
that the goals are uniquely determined by (or implicit within) the validated 
hiproof. 


3 Local Structured Queries 

How should we express queries on proof such as those in Section [l]? One design 
choice would be to take an existing query language for graph (or semi-structured) 
data models (e.g., see 0 f° r models and [ 1 ] for web query languages), and 
then map from hiproofs into the existing language and use queries there. The 
drawback with that approach is that we immediately lose connection with our 
particular source language, where it is most natural to express and study our 
queries. So instead we shall start from queries written in a minimal native query 
language, and investigate a direct semantics for them. 

Our queries follow the hiproof structure, matching on leaves with atomics, 
structured proofs using labels, or on input or output goals of subproofs. We 
consider queries which specify structure only locally , in the sense that they cannot 
directly compare one part of the tree with another, or measure absolute position 
within the global proof. This restriction arises because we use only first-order 
variables that refer to names and goals, not to subtrees or paths. Despite this, 
the language is still rather expressive and captures most of our desired queries. 

To introduce the language, we begin with constructs for matching leaves and 
goals within proofs, and then build up following the linear hiproof syntax. 

Matches. We build matches inside queries using wildcards, variables (which may 
get instantiated), constants (which have to match exactly) and, in the case of 
goals, some goal filtering predicates ip. Let VarN be a set of schematic variables 
standing for names, ranged over by N in general and A when we suggest an 
atomic rule name or L a label name. Let Vara be a set of variables standing for 
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lists of goals. The name matches and goal matches are given by: 

nm ::= a \ l \ * | N 
gm ::= [Vh, . . . , ip n ] \ G 

where stands for a logic-dependent predicate on goals 7 used to check some 
structural property of the goal term. For example we might have a predicate 
that checks whether a goal 7 is in the form of a horn clause, when (f>homciause{ 7) 
holds. In |2] we used such predicates in a tactic assert if) to influence the course 
of a proof, by failing if 1^(7) does not hold for the current goal. Most simply, we 
suppose that we always have a predicate to check for equality with any specific 
goal 7 and we overload 7 to stand for that predicate. 

We use matches to build up the basic queries which specify local structure. 
Informally, a basic query may hold for a given hiproof and a substitution of 
variables the query contains; we will define the result of a query to be the set of 
variable instantiations that make it true. As (merely) a matter of style, we use 
a verbose SQL-like textual notation: 


q ::= * 

| nothing 
| atomic nm 
| inside nm q 
| qi then q 2 
| qi beside q 2 
| ingoals gm 
| outgoals gm 


anything non-empty 
nothing (matches only identity) 
atomic rule match 

q satisfied inside box with label matching 
qi and q 2 satisfied by successive nodes in ; 
qi and q 2 satisfied by adjacent nodes in ® 
goals into sub-proof match 
goals out of sub-proof match 


Notice that the subject of the query is left implicit, phrases act as anchored 
patterns. This core is almost the same language as the hiproof syntax itself, 
omitting empty proofs and adding the ability to match on goals within the proof. 
Queries built using the first five of these constructors are called elementary. 

For the hiproof given in Fig. [I] the following queries are each satisfied (the 
alignment around then matches the vertical split): 


(inside I *) then (inside m *) 

(inside * * then * beside nothing) then * 

(inside L\ *) then (inside * atomic A) 


The first two are purely structural, matching the form of the tree. The first 
matches the outer structure consisting of the box labelled I followed by the box 
labelled m. The second examines the shape inside the first box. The final query 
is satisfiable with the (unique) instantiation Li 1 — > I, A 1 — > c. 


Connectives. We allow propositional logical connectives to build compound 
queries, with familiar intended meanings: 


I qi A q 2 
I qi V q 2 

I ~^q 
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Search and check. Two important quantifier combinators on queries allow us 
to search within a proof for somewhere that a query is satisfied, or check that 
a query is satisfied everywhere. With a syntactic interpretation, the natural 
domain of quantification is by subterm; because any subterm of a valid hiproof 
is also valid, this makes sense and we equate “subproof” (in the hiproof sense) 
with subterm. 

q::= ... 

| somewhere q q holds in some subproof 

| everywhere q q holds in every subproof 

The scope of somewhere and everywhere extends as far right as possible. 
These queries might be added directly to the language meaning, but we define 
them instead using recursion (introduced below). The somewhere combinator 
is used in many of our examples. For example, a proof uses a tactic tac if the 
query 

somewhere inside tac * 

is satisfied. As another example, we use a match on a goal-list variable G to find 
the goals passed into a tactic. The query 

(somewhere inside m ingoals G ) V (somewhere atomic b A ingoals G) 

can be read as “tell me the goals that are input to tactic m or the atomic rule 
b”. This would return the pair of instantiations {G ha [72], G ha [y 3 ]} for the 
hiproof in Fig. [l] 

When is everywhere useful? Clearly not for anything that requires a fixed 
structure, but with a goal-matching assertion that checks the format of the goals, 
for example, the check 

everywhere outgoals [ 0 homdause ] 

requires that every goal appearing in the tree must have that certain form. With 
conditional queries we can specify that only goals appearing in certain places 
must have some property. 

Recursive queries. Just as with tactics we can allow recursively defined queries. 
Recursively defined queries allow us to build up regular patterns. Singly-recursive 
queries can be defined using query variables Q: 

q::= ... 

I hQ-<l 

where q is a query in which Q can appear free. An example of a pattern query 
is: 

/r Q . (atomic a then (ingoals [72] beside Q)) V (inside m *) 

which is satisfied by proofs that repeatedly apply the atomic rule a, until reaching 
a box named m. 
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Using recursion we can define the searching and checking quantifiers de- 
scribed above: 

d&f 

somewhere q = /. iQ . q V (inside * Q) V (Q beside *) V (* beside Q)V 

(Q then *) V (* then Q ) 

everywhere q = 7 iQ . q A ((inside * Q) V (Q beside Q ) V 

(Q then Q) V nothing V atomic *)) 

these ensure that q holds at one (or every) node following the structure of the 
proof: notice that exactly one of the disjuncts must hold in the recursive cases. 
Later on we will show that these definitions have the intended meaning. 

Derived forms. Using this core, we can readily add more derived forms: 

i dcf 

qi when q 2 = ~^q 2 V q\ 

dcf a 

provesgoal 7 = ingoals [7] A outgoals [] 
axiom nm '= atomic run A outgoals [] 
islabel nm '= inside nm * 

isthen '= * then * 

a dcf a a a 

whenin nm q = inside nm q when islabel nm 

dcf a 

somewherealong q = /j,Q. <7 V (Q beside *) V (* beside Q) 

dcf 

separately q\ q 2 = /j,Q. (somewhere qi beside somewhere q 2 ) 

V (somewhere q\ then somewhere q 2 ) 

V (inside * Q) 

dcf 

nearby q = /iQ. q V (Q beside *) V (* beside Q) 

V (Q then *) V (* then Q) 

The when conditional combinator is satisfied if q\ is satisfied whenever q 2 is; by 
convention, the scope of qi and q 2 in when extend as far as possible. The last 
three combinators again use recursion to expand the scope of the local structure 
specifications. The query somewherealong q is satisfied if q is satisfied in a 
(g)-list of hiproofs; separately qi q 2 requires that <71 and q 2 hold on disjoint 
portions of the proof, arbitrarily separated. The query nearby q is an adjusted 
version of somewhere which restricts to the same level (without descending 
into labelled boxes). 

3.1 Examples 

Now we can write many of our motivating examples. For example, the input 
goals to tactic tac are simply the G that satisfy: 

somewhere inside tac ingoals G. 
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The tactic tac occurs recursively in a hiproof if the query 

somewhere inside tac somewhere islabel tac 
is satisfied. The tactic inner always occurs whenever the tactic outer is invoked: 

everywhere whenin outer somewhere islabel inner. 

A tactic named base always appears alongside a tactic named step inside the 
tactic induct: 

everywhere whenin induct somewhere (somewherealong islabel base) 

A (somewherealong islabel step). 

Further examples are given after looking at the semantics. 


4 Semantics 


We will define the semantics of queries using a satisfication relation s |= CT q. 
This denotes satisfication of a structured query on a hiproof s with respect to a 
substitution cr for match variables. The substitution maps variables N to names 
for atomic tactics and labels, and variables G to lists of the form [71, ... , y n ]. 
Two base satisfaction relations define matching on names and goal lists: 


* \=cr n 


n' \= a n 

iff 

N K n 

iff 

No - 9 

iff 

G \=cr g 

iff 


always 
n = n' 
a(N) = n 

3yi •••7 n-9 
a(G) = g 


[71,..., 7„] and ^1(71) • " i>n(ln) 


Before giving the main relation, we consider hiproof terms in more detail. 
Terms s in the hiproof grammar denote tree-based models in the denotational 
semantics of hiproofs pQ. Under the denotational interpretation, certain terms 
are equivalent. We will give our interpretation over the syntax, but closing under 
this equivalence. More specifically, we consider valid hiproofs given in Sect. 2 
modulo these equations: 


s ; id = s 

id is an identity for sequencing 

id ; s = s 

s 0 () = s 

() is an identity for juxtaposition 

() ® s = s 

s; (} =s 

() is a right-identity for sequencing 

s i ; ( s 2 ; S3) = (si ; s 2 ) ; S3 

; is associative 

si <8) (s 2 8) s 3 ) = (si 8 s 2 ) 8 s 3 

8 is associative 

(si ; s 2 ) 8 (s 3 ; s 4 ) = (si 8 s 3 ) ; (s 2 8 s 4 ) 

; and 8 can be exchanged 


main.ti 


293 2011-11-01 21 :44: 14Z da 


Querying Proofs 


9 


These equations are justified by the denotational semantics (which we omit from 
this paper), and it is easy to confirm that the equations preserve validity on the 
same lists of input and output goals for the rules in Fig. [2| We will write s = s' 
if two terms are equal in the theory generated by these equations (i.e. , closing 
also under congruence). We reserve s = s' to denote syntactic identity. 


Definition 1 (Query satisfaction). Let s be a valid hiproof and q a query in 
the minimal query language. The satisfaction of q for s with the substitution a 


d as the least relation s \= 

- a q satisfying: 

s \=„ * 

when 

HO 

id |= CT nothing 
a j= a atomic nm 

when 

nm 1 = 0 - a 

[Z] s 1 = 0 - inside nm q 

when 

nm H l and s \= a q 

si ; s 2 H 9i then q 2 

when 

Si H 9i and s 2 h<r q 2 

Si <g> s 2 1=<t qi beside q 2 

when 

Si her qi and s 2 H 92 

s |= CT ingoals gm 

when 

gm her g where s b g 

s \= a outgoals gm 

when 

gm her h where s \~ g 

S H 9l A 92 

when 

s her 9i and s \= a q 2 

S H 9l V 92 

when 

s her 9l or S her 92 

s |=o- 

when 

H H 9 ) 

s Hr fQ-q 

when 

s her q[h-Q.q/Q\ 

s Ho- q 

when 

3 s' . s' her 9 and s' = s. 


h 

h 


Recursive queries /.iQ.q are interpreted using unfolding; this suffices since we 
query only finitely deep trees. More precisely, we can define satisfaction using an 
auxiliary relation \= n indexed by the maximum depth of the number of unfoldings 
of a recursive query, where p n Q.q can be unfolded at most n times. Then |= is 
defined as the union of all finite unfolding relations \= n . The definition works 
for singly recursive queries where we do not need to interpret queries with free 
query variables, but can be extended standardly for mutually recursive queries. 


Proposition 1. Let s be a valid hiproof. Then 

1. s |= CT somewhere q iff 3s' .s' is a subterm of s and s' |=cr q, 

2. s |= CT everywhere q iff \/s'.s r is a subterm of s and s' \= a q. 

(where quantification ranges over non-empty terms, and s is a subterm of itself ). 

Thus these important derived forms have the intended meanings. 

How precise are our queries? The following proposition establishes, as in- 
tended, that every term can be characterised up to equality by a query. Thus, 
we can use queries to describe finite sets of hiproofs. 

Proposition 2. Given any empty-normal hiproofs, there is a query Q(s) which 
characterises s precisely. 
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Proof. Let Q(s) be given by the embedding: 

Q(id) = nothing 
Q([l) s ) = inside l Q(s) 

Q(si ; S2) = Q{s 1) then Q(s2) 

Q{s\ ® S2) = Q(si) beside Q(s2) 

Q( <» = -* 

Now we claim that whenever s' \= a Q(s) for some s' , we must have s = s' . 

How expressive are our queries? This is another natural question, which we 
discuss further below in Sec 14.31 


4.1 Examples and their results 

Now we demonstrate how some of our motivating queries are written in our 
language; meanings can be calculated using the semantics above to show that 
they are as desired. 

The invocation of a query to get some results can be written in SQL style as: 

select e from s where q 

which denotes the set of expressions a(e) for all substitutions a that satisfy the 
query. That is: 

Me) | s \= a q}. (2) 

The kind of expressions e chosen here depends on what we want to do with 
query results. We don’t consider a general transformation language for query 
results here, but one could easily allow expressions that combine pieces of query 
results in arbitrary ways, for example, building new hiproofs again over the query 
variables. Our examples below restrict to simple query variables. 

— To find all the axioms in a valid hiproof s: 

Axioms(s) = select A from s where 

somewhere axiom A 

Applied to s = ([/] a ; b <3 id) ; [to] c, this query returns {A i-a c, A i-a b}. 

— To find the existential witnesses inside a valid hiproof s, we can find uses of 
the existential introduction rule: 

Wit(s) = select A from s where 

somewhere atomic A A atomic Exit 

Strictly, this requires a slight generalisation of our atomic name matching to 
admit sets of names; we assume the ExI rule is annotated by the witness t 
that is chosen. 


main.ti 


293 2011-11-01 21 :44: 14Z da 


Querying Proofs 


11 


— Which goals are input to (or output from) a tactic called tac? 

Input{ tac, s) = select G from s where 

somewhere inside tac ingoals G 

Output{ tac, s ) = select G from s where 

somewhere inside tac outgoals G 

— Which tactics call themselves recursively? (shown earlier for fixed tac) 

Rec(s) = select L from s where 

somewhere inside L somewhere islabel L 


— Which tactic uses atomic tactic a, i.e., inside which label does a occur? 
Using the nearby combinator defined in the last section, this query returns 
all labels L which contain a directly, i.e., labels which are the immediate 
surrounding parent of a , not a more distant ancestor. 

Inside(a , s ) = select L from s where 

somewhere inside L nearby atomic a 

— Are there steps in the proof which have no effect? 

UselessTacs(s) = select L from s where 

somewhere inside L ingoals G A outgoals G 

This returns useless tactics that return the same goal that they were given 
(necessarily G must be a single element list by the hiproof structure). Of 
course, some tactics may be even worse and return the same goal that they 
were given and some more besides! To deal with these, we would need to 
extend goal matching to allow subset inclusion. 

— Are there duplicated subproofs inside a proof? A good way to answer this 
is to look for subtrees that have the same input and output goal lists, using 
the separately operator introduced earlier: 

Duplicates(s) = select Gi,G a from s where separately q q 

where q abbreviates ingoals Gi A outgoals G 0 


Of course, to return (or locate) the actual subtrees that prove the same 
things, we would need to extend the query language with variables ranging 
over hiproofs (or paths in hiproofs). See Sect. 4.3 for discussion of this. 


4.2 Query equivalence 

Prop. [^characterises proofs by queries. We can turn this around, and ask whether 
queries can be characterised by the proofs that satisfy them. This motivates 
a Leibniz-style equality between queries — two queries are equal if they are 
satisfied by the same proofs and the same substutions. This question is also 
motivated by complexity considerations — there may be more than one query 
to get a particular answer, but which one is more efficient? 


main.ti 


293 2011-11-01 21 :44: 14Z da 


12 


David Aspinall, Ewen Denney, and Christoph Lrith 


Definition 2 . We say two queries q, p are equivalent , written p = q, if for all 
proofs s and substitutions a, we have s \= a q •£=> s p. 

With this definition, we have the following groups of equations. First, the 


logical connectives distribute over the basic queries: 

inside nrn (p A q) = inside nm p A inside nm p (3) 

inside nm (p V q) = inside nm p V inside nm p (4) 

p then (<71 A q 2 ) — (p then q{) A (p then q 2 ) (5) 

(pi A p 2 ) then q = (pi then q) A (p 2 then q) ( 6 ) 

p then (qi V q 2 ) = (q then qi) V (p then q 2 ) (7) 

(pi V p 2 ) then q = (pi then q V (p then q 2 ) ( 8 ) 

p beside (qi A q 2 ) = ( p beside qi) A (p beside q 2 ) (9) 

(pi A p 2 ) beside q = (pi beside q) A (p 2 beside q) (10) 

p beside (q x V q 2 ) = (p beside qi) V (p beside q 2 ) (11) 

(pi V p- 2 ) beside q = (pi beside q V (p beside q 2 ) (12) 

Alternatively: 

inside nm (pDq) = (inside nm p)D(inside nm pq) (13) 

{p\Up 2 )®q = (pi®q)n(p 2 ®q) (14) 

pO(qiDq 2 ) = (p®qi)D(p0q 2 ) (15) 

for □ € {A,V} and (g) £ { then , beside }. 


Secondly, negation distributes over the basic queries in the following fashion. 

For example, a query inside Im q is not satisfied by s if s is either not of the 
form [/] s', or if it is and s' does not satisfy q. This gives us: 

^(inside Im q) = inside Im (^q) V (atomic *) V (* beside *) V (* then *) 

(16) 

->(p beside q) = (^p) beside * V * beside (^q) V (atomic *) V (inside * *) V (* then *) 

(17) 

->(p then q) = (^p) then * V * then (^q) V (atomic *) V (inside * *) V (* beside *) 

(18) 

Finally, we have the deMorgan equalities, double negation, commutativity and 


distributivity of conjunction over disjunction: 

~ '(p A q) = (—<p) V (~<q) (19) 

-'ip V q) = i~^p) A (->q) (20) 

-^(-‘P)-P (21) 

{Pi V P 2 ) A q = (pi A q) V (p 2 A q) (22) 

(pA (qi Vq 2 ) = (pA qi) V (pA q 2 ) (23) 

(24) 
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Equations ([3]) to (23) are proven by expanding Def.[2]and using Def. [l] Example 
here? Seems all rather obvious. From these equations, we can get the notion 
of a normal form. 


Definition 3 (EEF and DNF). A query is in extended elementary form 
(EEF), if it is an elementally query, a negation of an elementary query, or 
inside nm q where q is an extended elementary query. 

A query q is in disjunctive normal form (DNF), if it is of the shape V i=1 n /\j=i m 
where cf>ij are extended elementary queries, or in other words a disjunction of 
conjunctions of extended elementary queries. 

Theorem 1. For each query q, there is a an equivalent query q' , denotated as 
DNF(q), such that q = q and q' is in DNF. 


Proof. The proof proceeds by structural induction on q. Given an arbitrary q , 
we first push negation inside using equations (16) to (20). Now, using equations 
(|3j) to ( 12 ) we can push the query constructors (inside, then, beside) inside 
the logical connectives. Finally, use (22) and (23) to transform the formula into 
a disjunction of conjunctions. 


ToDo: 


— How big does it get? Blowup seems quadratic (note the negation equations 
only add a constant overhead) at each step- is that polynomial or exponential 
in total? 

— Need to handle recursion. 


4.3 Towards globally structured queries 

There is a limit to what queries in our language can express. We call these queries 
locally structured because they are based on building up patterns of structure 
that are matched implicitly to a position in the tree. Using variable substitution 
and structural recursion, queries can span and relate different portions of the 
tree, but it is not possible to write a query that directly refers to (or returns) a 
position in the tree, or does any counting. 

This limitation can be lifted, e.g., by adding a notion of path to the language, 
so we have a way to refer to positions in the tree. We have refrained from doing 
that in this paper to study the restricted case in detail first. 

— TODO: something on expressivity/complexity: maybe say/show that with 
paths, queries are more succinct; maybe show a query that cannot be ex- 
pressed although result is in the language (i.e., some substitution of label- 
s/axioms/goals). 
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5 Implementing Queries 

We have implemeted a prototype of the query language for small experiments. It 
represents queries as an algebraic datatype Q, and in time-honoured fashion uses 
SML as both implementation platform and scriptable command-line interface. 
Hiproofs are represented modulo the equations in Sect. [4j following the denota- 
tional semantics in [I]. The implementation is a functor which is generic over 
the proofs in question, reflecting the generic nature of the query language. 

Corresponding to the semantic interpretation in Def. [l] the implementation 
provides a function: 

val sat : P . HiPrf -> Q -> Subst list 

which calculates the set of possible substitutions of query variables for names 
and goal lists to satisfy the given query; a satisfiable query with no substitution 
yields a singleton result of the empty substitution, while an unsatisfiable query 
yields the empty list as a result. 

The function sat is a straightforward recursion over the structure of the 
query; the hiproof equations are taken care of by using a canonical (denotational) 
representation. For the basic queries an auxiliary function match_nm implements 
matching on atomic tactics and labels, and match_gm similarly for goals. Cru- 
cially, most compound queries are conjunctive: they decompose the argument, 
obtain sets of results for each of the subqueries, and then combine by pointwise 
unification of the resulting substitutions. (The unification here is very simple, 
just checking that the same variable is not mapped to different atoms, labels or 
goals, so it is a partial function.) In Haskell-like syntax, this is written as: 

rl >> rl = [ s | sl<-rl, s2<-r2, SOME s<-unify(sl, s2) ] 

In contrast, to combine the results of disjunction it suffices to concatenate the 
result lists. Roughly, sat is implemented with cases like this: 

sat (Atom a) (Atomic am) = match_nm(a, am) 

sat (Lab 1 s) (Inside lm q) = match.nm (1 , lm) >> sat s q 
sat (Seq si s2) (ql Then q2 ) = sat si ql >> sat s2 q2 

sat s (ql And q2 ) = sat s ql >> sat s q2 
sat s (ql Or q2 ) = sat si ql @ sat s2 q2 

sat s q = [] 

We provide two instantiations of the generic implementation: one for the 
syntactic hiproofs, where we have a datatype S as in |T]), and one which models 
Isabelle proof objects as hiproofs. 

5.1 Isabelle Proofs 

Needs to be cleaned up. Notes about Isabelle proof objects: 

— They have an inherent hierarchical structure, which may or may not be what 
we want. Boxes correspond to proven theorems; skeleton reduces a proof to 
the proof down to the axioms of the logic. 
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— How to model sequence and tensor? Need to divine from structure of proof 
and arity of rules (theorems). 

— This means queries are not logic-independent. The axiom query always work, 
but the recursive-tactic query now means does a theorem use itself in its own 
proo. 

— Isabelle proof objects do not have any information about the high-level proof 
scripts used to create them. We can add this information by using vacous 
“label theorems” which are just <f> — > <j>, but the names of which carry 
labelling information. The hierarchical structure will now only take account 
of the label theorems. 


5.2 TSTP 

Proofs in TSTP consist of the sequence of formulas output by an automated 
theorem prover, including axioms, conjecture, and derived formulas. All formulas 
have a source. For derived formulas the source indicates the inference rule and 
antecedent formulas from which it was derived. For a leaf formula the source is 
the original location of the formula. TSTP, itself, does not have any notion of 
inference rule — these are supplied by the underlying provers. 

Consider the underlying proof on the right of Fig. [T] This can be translated 
into TSTP in either a forwards style, where we start with formulas, 72 and 
73 given by axioms b and c, respectively, and then apply inference rule, a, to 
conclude 71, or in a backwards style, where we start with conjecture 71, apply a 
to get two sub-goals, and then discharge them with the corresponding axioms. 
The TSTP representations of these derivations are quite different, though they 
have a single analogous proof tree. 

Although TSTP does not represent tactics, inference rules can be nested, 
giving a simple form of hierarchy. We could also look to decompose the deriva- 
tions thus deriving an implicit hierarchy, or extend the language with labels on 
sub-derivations to represent hierarchy explicitly. 


6 Related work and conclusions 


This paper introduced locally structured proof queries in our proof query lan- 
guage, PrQL. Much remains to be done. Further work will extend the language 
to globally structured (higher-order) queries and queries defined directly over 
our semantic models. To explain implementation strategies, we ought to give a 
more precise account of how queries are evaluated: this might be with a direct 
operational interpretation, or via an auxiliary mechanism. Further out, we want 
to set this work in the context of related query languages, perhaps by trans- 
lations. We plan to investigate mappings from PrQL to both PML and TSTP. 
Via mappings to other foundational query languages for graph models, we may 
derive expressivity and complexity results (see e.g., 0 ). 
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Related work in theorem proving. The idea of a general query language for in- 
specting formal proofs appears novel, although there are many investigations 
into exploiting proofs using ad hoc features to reference or manipulate parts of 
proofs. We can’t survey all but mention a few. Connecting decision procedures 
to theorem proving, researchers added invocation records (and perhaps justi- 
fications) grafted into an overall proof or justification (e.g., jB]). Noteworthy 
sub-trees may be represented using names for reference (and then shared to cre- 
ate a dag structure) as in TPTP and its proof format TSTP [7 . Many systems 
use debugging output for proof procedures to create a lengthy log, which explains 
where things were tried and failed. Some tools use representations of proof trees 
in the first place which connect the proof-producing mechanism to the proof 
and are equipped with browsing and editing mechanisms, e.g., NuPrl [8]. The 
strand of research into proof- carrying code has taken the independence and de- 
pendability of proofs (and more generally, certificates for search procedures) very 
seriously |J5|. Besides checking proofs, other researchers made efforts to translate 
proofs between systems EDI; ways to discover dependencies between parts of 
proofs EH to help simplify or rearrange; and ways to mine proofs to discover 
common patterns [12], 

TSTP proofs can be queried by translation E3j into the Proof Markup Lan- 
guage (PML) [H], which provides an interlingua representation for the justifica- 
tion of results produced by Semantic Web services. PML represents both proof 
and provenance level information. Queries in PML are simply partial proofs, 
rather than expressions in a separate query language (although PrQL also has 
similarities to its underlying proof language) , and query evaluation seeks to re- 
turn (possibly partial) proofs that “fill in the blanks” in the initial query. A 
browser also allows certain forms of querying. 

Query languages for structured data and programs. Away from theorem proving, 
query languages for trees and graphs have been studied for some time. Languages 
related to PrQL include those aimed at semi-structured (XML-like) models such 
as UnQL [15] which uses structural recursion on tree (and graph) representa- 
tions, similarly to PrQL’s recursive queries, and Graph Logic m which uses 
a separating conjunction to destruct the graph subject of queries. Checking for 
patterns in programs, ASTLog EH is a Prolog variant for examining syntax 
trees and PQL [^j is a more general framework for querying programs based on 
examining a program text at varying levels of abstraction. 
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